Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/824

Internet Message Format | 1994-08-27 | 15.9 KB

Date: Sun, 17 Jul 1994 13:10:23 -0400 (EDT)
Date: Sat, 16 Jul 94 02:34 EST
Subject: Gem List (fwd)
Subject: Gem List
Subject:  Re: Buttons Buttons Buttons
Subject:  Re: Buttons Buttons Buttons
Subject:  Re: Online Help
Subject:  Digest
Subject:  RE: Re: Buttons Buttons Buttons
Subject:  Re: RE: Re: Buttons Buttons Buttons
Subject:  Re: Dialogs & Extra Buttons
Date: Sun, 17 Jul 1994 13:10:23 -0400 (EDT)
Mime-Version: 1.0
Precedence: bulk

Forwarded message:
>From [e-mail] Sat Jul 16 03:37:08 1994
Date: Sat, 16 Jul 94 02:34 EST
From: "Daniel J. Hollis" <[e-mail]>
To: ems <[e-mail]>
Subject: Gem List
Message-Id: <50940716073405/[e-mail]>

Subject:  Re: Buttons Buttons Buttons

Warwick:
--------
>Ofir Gal wrote:
>>2. Holding the right button allows clicking in background windows with the
>>   left button, very useful and also the standard behaviour. Works very
>>   well in the desktop and Papyrus is another example where you can move
>>   the cursor around and even select text while in the font selector.
>This is an incredible waste of a button.  It also violates the principle
>of not requiring the user to hold down multiple buttons to perform an
>action.

For once we agree. :-) *NO OTHER GUI* requires a right click combo to
get at background window gadgets. It's a waste of time, and it's a stupid
design. It wastes a button that could otherwise be used for something
more useful like a *tool*, rather than *wasting* it on background buttons.

>>3. Allow the right button to be used on background windows without topping
>>   them. I personally find this very useful and implemented it in my
>>   toolkit as a user option. It is also used in Datalite and Ease where
>>   you can move/copy/drag files without having to top windows.
>Totally confusing.  All you need to do is allow the user to use the window
>title, or any unused area of the window to top the window.  In an extreme
>case, also allow a meta key, such as Alt-Ctrl to make the left button top
>the window.

My philosophy is that there should be *NO DISTINCTION ON BUTTON
FUNCTIONALITY* whether a window is in the 'background' or 'foreground'. The
*SAME BUTTONS* should work on the *SAME WINDOW* whether it's topped or not.
Changing the mouse buttons required to click a gadget in the *SAME WINDOW*
depending on its level in the window stack gets totally confusing.

>I have my WINCOLOURS set up so that the top window is very little different
>to untopped windows (just the title text changes colour).  This infatuation
>GEM has with topping windows is something we should be getting away from,
>not setting in stone standards.

Agreed. If the appearance doesn't change, why require a change in mouse
button behaviour?

>If you use MultiTOS, you'll soon become tired of topping windows if you
>move back and forth between applications, and if you have a large enough
>screen to have multiple non-overlapping application windows.

This is even more apparent in Windows where MDI applications have children
windows in their main window. Under normal Windows if you click on one
of those child processes, you'll bring the whole damned parent application
*AND ALL OF ITS CHILD WINDOWS* to the top. This is totally stupid, especially
if you're trying to do something productive.

There is a PD patch program called (interestingly enough) 'WinX' (no, this
is not the same WinX as on the Atari, it is by a different person) for
Microsoft Windows, and it allows you to activate background window gadgets
without having to top them first. This is very very useful, i.e. you've got
a word processor open, and file manager with 3 or 4 child windows. I can keep my
word processor window topped and scroll the background child windows up and
down to reference files for a document I'm writing. If I had to keep topping
and untopping applications, the job would take 10 times longer.

WinX also lets you keep the keyboard 'focus' on a certain application if you
like, so you can background a word processor window and still keep typing
into it. Not exactly useful, but.... :-)

It also has an option to automatically top windows that the mouse enters,
but I find this 'feature' annoying as hell. Fortunately WinX allows you to
turn this off.

It also has a nice feature in that you can mark a window as 'always topped'
so that it can never be obscured. This is nice for programs which don't have
such a feature internally.

WinX also lets you 'pull' any window forward one level, or push it back
one level (or all the way to the back), without having to 'top' it first.
This is handy for rearranging the window stack without having to un-top the
application you're currently using.

My philosophy is, the functionality of the GUI should not get in the way
of the user, it should make life EASIER for the user, not more difficult.

--Dan Hollis
----------
Subject:  Re: Buttons Buttons Buttons

>>This is an incredible waste of a button.  It also violates the principle
>>of not requiring the user to hold down multiple buttons to perform an
>>action.
>I totally disagree, I wouldn't want Papyrus to work in any other way. It
>doesn't violate anything, this is the way the desktop has behave[d] for the
>last 5 years.

Just because the desktop does it that way doesn't mean it's the right way.

The desktop allocates all of RAM for even a 0 byte file copy, but you would
think this is the right way to do things simply because the desktop does it?

MS-DOS is limited to 640k, but this does not mean that Microsoft is correct
in their design. But you would argue that a 640k limit is perfectly
acceptable just because it's been that way for 8 years.

>>>3. Allow the right button to be used on background windows without topping
>>Totally confusing.  All you need to do is allow the user to use the window
>>title, or any unused area of the window to top the window.  In an extreme
>>case, also allow a meta key, such as Alt-Ctrl to make the left button top
>>the window.
>Why? And what is an 'unused' part of a window?

Actually it should be : 'click' TOPS a window
                        'press' ACTIVATES a window gadget

Is this so difficult to understand?

>What has mouse button response to do with screen resolutions? All the
>programs I have run happily in 880*656 and still manage to follow this
>standard mouse behaviour.

Atari's "standards" are not always the correct ones. Besides the fact
that atari did not 'declare' the mouse button behaviour as a standard --
it is still open to interpretation.

--Dan Hollis
----------
Subject:  Re: Online Help

>>Has any discussion gone into a standard for online help on the GEM
>>list yet?

IMHO, PureC's help system is acceptable. Programs like CoNnect have
similar help systems, but IMHO CoNnect goes a little overboard :-)

>>I remember some mentions of 1st Guide, but that was lost in the tidal wave
>>of keyboard shortcut discussion...
>We have started talking about this. There are several items that need
>further discussion:

>Non-modal dialogues

Modal dialogs (i.e. do_alert) should be avoided in 99.9999% of cases.
'modal' dialogs should be modal for only 1 application (i.e. windowed
modal dialog) and should NOT stop task switching for other applications.

Only catastrophic errors (i.e. virtual memory manager crashes, etc. :-)
should bring up a system-wide modal dialog (i.e. do_alert). If some program
brings up a 'printer not connected' alert box, your background BBS program
will halt. This is totally unacceptable.

>Palette handling

Simple. First 16 colors are 'reserved' standard colors that any application
can depend on NOT changing. The remaining colors can be changed by any
application. It would be nice if there were some standard method where
programs could 'allocate' colors they needed, but this is not possible with
the normal VDI.

>keyboard shortcuts config file

This *DOES* need discussion. It is a very very good idea, IMHO -- let the
users choose whatever damn key equivalents they want. They can customize
the key equivalents to their own local country keyboard.

>right mouse button behaviour

Should be a non-issue, IMHO. The same mouse buttons should have the exact
same effect on a window whether it's topped or not. Doing otherwise is
totally confusing.

>menu layout

This definitely needs discussion.

--Dan Hollis
----------
Subject:  Digest

Chris:
------
>> You have to understand how GEM works before you can bring up an argument
>> like this. The fact is that not every application will get a mouse event
>> unless they write their own mouse routine (not everyone is willing to do :-
>But surely your proposal is that everyone will have to to implement your
>standard? It's not a problem now but if you make it mandatory you will have
>all programs doing it, which slows it down.

Have you actually TRIED this? Are you ASSUMING it will slow things down, or
are you speaking from experience having tried this? Try first, then comment
later. From experience, the speed difference is so incemantable, that it's
not even funny. ANYONE can LIVE with the speed difference: There is none that
you can see with the naked eye!

BTW, having all programs do it, or none do it, is better than some doing
it and some not. I prefer consistency over everything else.

>> There is another problem here -- our library allows you to set multiple
>> timer events and 'attach' them to windows. If we set our event_timer to
>> wait for rectangle events, then the timers would become effectively
>> useless. The library does need to do events on a regular basis, but only
>> mouse events will be done if the application is TOPPED.
> What does using mouse rectangle events have to do with whether you receive
> timer events anyway?

Nothing. The problem is that we sub-divide out timer events to subroutines
to do internal multitasking. If we were to use a longer timer event than 0,
it would slow down internal multitasking.

Since we've got a timer event of 0, waiting for a rectangle event is useless
(and we watch rectangles internally anyways, which is faster...)

>> Extended object types can *easily* handle behavioural objects. Just look
>> at WinLIB PRO's active sliders. Those are just normal everyday sliders,
>> with the one addition that their extended object type is different.
>>
>> You're saying that with Gem++ you would have to add code to support the
>> active slider, perhaps doing something like "register_active_slider(TREE,
>> object, orientation);" which is insane. Having to write code to support
>> an interface when the interface should do those things ITSELF is a pain.
> But you need to attach code to the active slider anyway, or any other type of
> object. For example you might have a check-box object which is handled
> automatically, but you still have to specify the code for it, perhaps in a
> switch statement. In GEM++ you just declare that the existing button should be
> a check-box of a particular application specific class, and it changes the
> behaviour and appearance.

In WinLIB PRO, you attach a routine to a *button*, but that code doesn't
affect the appearance of the item it's attached to in any way.

You are still pointing out the fact that if you want to change the APPEARANCE
without changing the functionality, in Gem++ this is impossible without
a code change and re-compile.

Face it, this is a *BIG* disadvantage.

>> Besides the fact that if you want to change the functionality of a button,
>> you can't do it visually, you have to do it programatically. This is
>> right along the lines of insanity that MultiTOS did when they forced you to
>> do heirarchical menus by linking them together within your code, rather
>> than the *obvious* way of allowing you to design heirarchical menus using
>> a resource editor.
> You can still edit them in a resource editor. From your code you declare an
> object and this attaches code to them and may optionally change the
> appearance. You cannot do it from a resource editor because there are an
> infinite number of different types of code that may be attached.

Sounds like Gem++ is the only library which has this limitation. Every other
library can make these kind of changes in mere seconds, with a resource
editor, no code changes required, no recompiliation required.

In the end, Gem++ loses out by making the programmer's life more difficult.

> Have you used GEM++? Were there a decent fast c++ compiler for the Atari I
> would use it all the time.

Think about what you just said here :-)

--Dan Hollis
--------
Subject:  RE: Re: Buttons Buttons Buttons

> Does anyone use the hold-right-button-while-click-left on the
> desktop? Well I certainly use it a lot when copying files
> accross and not wanting to swap top windows!

Just because Atari's Desktop does it doesn't mean it's right.

> IMHO, Holding down the right mouse button is pretty natural. You
> can't (as far as I know) stop a left click from topping a window
> in older TOSes anyway, so you must have hold right and then click left, or
> simply click right. Since I like the idea that LEFT IS SELECT, I'm not a
> great fan of using the right mouse button instead.

Pardon me a minute... *ahem*...

** BWAHAHAHAHAHAHAHHAHAHAHAHHAHAHAHAHHAHAHAHAHHAA!!!!!!! **

Ok: This behavior is possible under *ANY* version of TOS, even all the way
back to 1.0 (we were doing background button clicks, etc. on TOS 1.0 with
WinLIB PRO).

When you receive a WM_TOPPED message from AES, YOU top the window yourself,
not AES. AES just sends you the message, AES doesn't top the window for you.
You can choose to ignore the WM_TOPPED message completely, or interpret it
however you like; remember, the topped window's ID is returned in this
message. There's your clue for the day. :P

This is the *key* to background buttons, BTW. And it's *VERY* easy to
implement using this method.

> The idea of topping a window only if the left-click doesn't hit a button or
> edit item is quite appealing but surely not available in older TOSes. I
> think we should avoid having different behavious on different machines.

Here's a simpler solution:

       'click' anywhere in a window always tops it.
       'press' activates a gadget.

Understand now? :-)

--Dan Hollis
--------
Subject:  Re: RE: Re: Buttons Buttons Buttons

Ofir:
-----
>>IMHO, Holding down the right mouse button is pretty natural. You
>>can't (as far as I know) stop a left click from topping a window
>>in older TOSes anyway, so you must have hold right and then click left, or
>>simply click right. Since I like the idea that LEFT IS SELECT, I'm not a
>>great fan of using the right mouse button instead.
> In my programs the right button behaviour is selectable between the
> desktop hold-right to the right driver method.
> I think that it should be up to the programmer to give the user the option
> of using WF_BEVENT for toolbar windows or whatever.

That is a great idea, let the user configure the interface for their
preferences.

I think we might implement two operating modes for WinLIB PRO:

'Normal user mode' - buttons operate the correct way (i.e. left click in
                     foreground and background windows), click anywhere
                     in a window to top, press gadgets to activate.

'Moron user mode'  - buttons operate idiotic way (i.e. left click in
                     foreground windows, left+right click in background
                     windows), click only in non-button areas to top a window,
                     click to activate buttons. pressing background buttons
                     is not available.

--Dan Hollis
----------
Subject:  Re: Dialogs & Extra Buttons

Annius:
-------
> OK,  let's compare this to everyday life then.  In public buildings,
> what signs are always most clearly recognizable?  You got it,  the
> emergency exits.
> The fact that there is often confusion between different negative
> actions is enough to justify a special position of Cancel.  OK already
> has the optical advantage of being thicker AND it is activated using
> the Return button.

This is a good point:

'Format hard disk : Are you SURE? [[ OK ]] [ Cancel ]'

is the wrong way.

'Format hard disk : Are you SURE? [[ Cancel ]] [ OK ]'

is more acceptable.

--Dan Hollis
--------